In the past several years, machine-to-machine (M2M) has spread into the mobile communications arena and M2M implementation continues to grow at a rapid pace. M2M generally refers to transferring information by using a communication network to exchange data from a machine to another machine that is implementing interconnection and internetworking between machines by using the communication network. The standards for M2M implementation are set forth in the European Telecommunications Standards Institute (ETSI) M2M standards. The ETSI M2M standards define concepts of a M2M network application (NA) and M2M device application (DA) that are M2M applications that run the service logic and use M2M service capabilities, network service capability layer (NSCL) that is the M2M service capabilities in the network domain, and service capability layer (SCL) as well as other concepts that are defined in the standard(s). In particular, the current ETSI M2M standards support NSCL to NSCL communication that is used for inter-operability between two M2M service providers.
However, the ETSI M2M standards make some implicit assumptions about inter-operability between two M2M Service Providers. For example, each M2M entity (hidden or visible) and a gateway (special type of visible entity) that is an M2M subscriber to a specific M2M service provider, may perform operations (read, subscribe, etc.) on other resources in another M2M domain if permitted to do so. Typically, being able to perform such operations requires business agreements and the operation is usually limited to reading resources and not more than that. While within the domain of the M2M SP for an M2M entity or device, the range of operations is much larger as the M2M device can create resources, write to resources, subscribe to resources, announce one resource to others, etc. but still subject to appropriate access controls.
Another implicit assumption is that each M2M entity/device (hidden or visible) and the gateway that is an M2M subscriber to an M2M service provider is required to first be authenticated with the M2M SP before the M2M subscriber can perform any operation. Another implicit assumption is that each operation going across multiple M2M SPs must go through the NSCL of each M2M SP in which the NSCL acts as a border between the two SPs across which all traffic between them has to transmit. More importantly is the assumption that a gateway can only be authenticated with the M2M SP that supplied the gateway. Therefore, an SCL instance belonging to a second M2M SP and that is resident and executes on a gateway supplied by the first M2M SP cannot perform any operation with the second M2M SP since the gateway can only be authenticated with the first M2M SP, as illustrated in FIG. 1.
Referring to FIG. 1, system 2 includes first SP gateway node 4 that is a special type of visible entity in the first M2M SP's domain. The first SP gateway 4 may only be authenticated by first M2M SP node 10a. First SP gateway node 4 may have subscriptions to the first M2M SP such that Gateway is associated with first SCL 6 of the first M2M SP. System 2 may include a first M2M SP node 10a with corresponding first NSCL 14, and second M2M SP node 10b with corresponding second NSCL 16. The first M2M SP is different from the second M2M SP. As illustrated in FIG. 1, first SP gateway node 4 is unable to communicate second SCL traffic with second M2M SP node 10b under ETSI M2M standards since first SP gateway node 4 cannot be authenticated by second M2M SP node 10b. Gateway node 4 is only able to be authenticated by first M2M SP node 10a to which gateway node 4 belongs. Therefore, first SP gateway node 4 having a subscription to a second SCL 8 belonging to second M2M SP node 10b would be useless as first SP gateway node 4 is unable to transit second SCL traffic to the second M2M SP node 10b. 